<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

Wire Metro’s code-fence removal to **builds.yml** on GitHub Actions
while keeping Bitrise/local behavior unchanged.

**Why:** On GH Actions, build config (and thus which features are
enabled) comes from `builds.yml` via `apply-build-config.js`, which can
set `CODE_FENCING_FEATURES`. Metro previously only used
`METAMASK_BUILD_TYPE` and `METAMASK_ENVIRONMENT`, so code fencing did
not follow the same source of truth.

**What changed:**

- **GH Actions:** When `CODE_FENCING_FEATURES` is set, Metro uses that
JSON array for code-fence removal; `INCLUDE_SAMPLE_FEATURE` still adds
`sample-feature` when set.
- **Bitrise/local:** When `CODE_FENCING_FEATURES` is not set, behavior
is unchanged: features are derived from `METAMASK_BUILD_TYPE` +
`METAMASK_ENVIRONMENT` via `getBuildTypeFeaturesFromEnv()`.
- **Safety:** The env-based fallback returns new `Set` instances so
adding `sample-feature` (or other mutations) does not mutate shared
global sets.
- **Docs:** Comments and JSDoc clarify the “legacy” (Bitrise/local) vs
“GH Actions” paths.

**Scope:** Only `metro.transform.js` (no workflow or script changes in
this PR).

---

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: Added code fencing for gh actions defined at builds.yml

## **Related issues**

Fixes: 

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**
checking code fencing in all builds ✅ 
main-rc
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/75d11555-3f76-4f80-bb48-c6a45cb99d64"
/>
main-exp
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/04487ad6-359c-448c-9660-f2e139f88dbf"
/>
main-test
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/319eb592-691f-4abe-93f3-f3a0467ac0bc"
/>
main-beta
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/c38416cb-706f-488f-a031-bcac2d811d8c"
/>
flask-test
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/12224fd6-6ac2-4726-b7f4-43ca10ea2f59"
/>


## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [x] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [x] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.



<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes the source of truth for code-fence feature gating in CI
builds, so misconfigured `CODE_FENCING_FEATURES` could include/exclude
fenced code unexpectedly across release flavors.
> 
> **Overview**
> Metro’s code-fence removal now **prefers `CODE_FENCING_FEATURES` (JSON
from `builds.yml` via CI)** as the active feature set, falling back to
the prior `METAMASK_BUILD_TYPE`/`METAMASK_ENVIRONMENT` logic when unset.
> 
> `builds.yml` expands code-fencing anchors to explicitly define `beta`
and `experimental` feature sets, and updates the `main-beta` and
`main-exp` build configs to use them; the Metro fallback path also now
returns fresh `Set` instances to avoid mutating shared feature sets when
optionally adding `sample-feature`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
c474217. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Wei Sun <wei.sun@consensys.net>